home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19960715-19961006 / 000102_news@columbia.edu _Tue Jul 30 13:42:40 1996.msg < prev    next >
Internet Message Format  |  2020-01-01  |  4KB
  1. Return-Path: news@columbia.edu
  2. Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30]) by watsun.cc.columbia.edu (8.7.5/8.7.3) with ESMTP id NAA11910 for <kermit.misc@watsun.cc.columbia.edu>; Tue, 30 Jul 1996 13:42:40 -0400 (EDT)
  3. Received: (from news@localhost) by newsmaster.cc.columbia.edu (8.7.5/8.7.3) id NAA28541 for kermit.misc@watsun; Tue, 30 Jul 1996 13:42:39 -0400 (EDT)
  4. Path: news.columbia.edu!watsun.cc.columbia.edu!fdc
  5. From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
  6. Newsgroups: comp.protocols.kermit.misc,comp.dcom.modems
  7. Subject: Re: Problem getting 28800 bps in C-Kermit 5A(190) on a v.34 internal
  8. Date: 30 Jul 1996 17:42:17 GMT
  9. Organization: Columbia University
  10. Lines: 73
  11. Message-ID: <4tlhhp$fm8@apakabar.cc.columbia.edu>
  12. References: <CROTEN.96Jul24005129@crl.crl.com> <1996Jul28.193939.943@ia-us.com> <CROTEN.96Jul28153957@crl.crl.com> <1996Jul30.164039.1803@ia-us.com>
  13. NNTP-Posting-Host: watsun.cc.columbia.edu
  14. Xref: news.columbia.edu comp.protocols.kermit.misc:5674 comp.dcom.modems:146136
  15.  
  16. In article <1996Jul30.164039.1803@ia-us.com>,
  17. Glenn Herteg <glenn@lia.com> wrote:
  18. : >I get the same sort of behavior .. with an internal modem, low CPU loading, 
  19. : >and rtc/cts flow control.  You earlier mentioned that the misbehavior was, 
  20. : >you suspected, at the device-driver level.  Perhaps it is independent of 
  21. : >these other issues.  
  22. : 
  23. : Frank has indicated the likely problem; I'll upgrade my kermit and run
  24. : some tests.  I had not done the upgrade before because the version I use
  25. : seemed otherwise fine, there was a clear workaround, and I felt I had no
  26. : right to expect a protocol to work when I'm telling it to depend on a
  27. : transport known to be broken.  Frank seems to feel otherwise, so okay,
  28. : I'll take up the challenge.
  29. : 
  30. : (The other reason I didn't upgrade had to do with the default behavior
  31. : on transferring partial files.  It's possible in the 190 version to have
  32. : partial files left around, and you get no notice of this.
  33. :
  34. Right, the *default* changed.  This is to allow recovery of broken
  35. transmissions, a much asked-for feature.  You can, of course, restore the
  36. previous behavior of discarding patially received files by putting the
  37. following command in your .kermrc:
  38.  
  39.   set file incomplete discard
  40.  
  41. and/or you can test whether a transfer succeeded (even if you do keep
  42. the fragment from a failed transfer) using SHOW STATUS, IF SUCCESS ...,
  43. looking in the transaction log, or in any number of other ways, including...
  44.  
  45. : I suppose the fullscreen display would tell me that at the end of the
  46. : transfer.  But if I'm using an xterm [for instance; lots of terminals
  47. : have this "problem"] then the fullscreen display flips into an alternate
  48. : screen, which [kazaam!] disappears once the transfer is done.
  49. :
  50. Well, that's not nice of your xterm.  Using a normal terminal or emulator,
  51. this doesn't happen, and you have the entire transfer display to look at
  52. after the transfer is done.  Not a Kermit problem.
  53.  
  54. : There went my notification of success or failure.  [To fix this, I think a
  55. : simple success or failure notification, and the name of any partial file
  56. : left hanging around, ought to be repeated on the original screen once
  57. : fullscreen mode ends.]
  58. :
  59. And others think we are way too verbose already :-)  But that's what the
  60. macro language is for:
  61.  
  62.   define verbosesend send \%1, show status
  63.  
  64.   define verbosereceive receive, -
  65.     show status, -
  66.     xif fail { echo, echo PARTIAL file received: \v(filespec), echo }
  67.  
  68. By the way, the next release of C-Kermit will indeed have a CRC generation
  69. and checking feature, so you will be able to do the following to verify
  70. that a binary-mode transfer produced the desired result, assuming you have
  71. a Kermit client and a Kermit server that both support this feature:
  72.  
  73.   set file type binary
  74.   send (or get) (one or more files)
  75.   remote query kermit crc16
  76.   if not = \v(query) \v(crc16) echo CRC mismatch
  77.   else echo CRC comparison OK
  78.  
  79. (Replace the ECHO commands with whatever you need to handle failure and
  80. success.)
  81.  
  82. This feature uses the CRC-16 code that has proven itself portable to over
  83. 500 different platforms -- 16-bit, 32-bit, 64-bit -- over the past 10 years,
  84. so you don't have to worry about sign extension, endianness, word size or
  85. other problems that "man sum" hints at.  Plus, unlike "sum", it will be
  86. available in other operating systems besides just UNIX.
  87.  
  88. - Frank